Questions

7 of 15

1What are the main categories of data types available in MySQL?

2What is the difference between CHAR and VARCHAR data types?

3Which data type would you use to store dates and times in MySQL?

4What is the difference between INT, FLOAT, and DECIMAL data types?

5What is the use of the TEXT and BLOB data types, and how are they different from VARCHAR?

6How does MySQL handle precision and scale in DECIMAL(M, D) columns internally, and how do these differ from FLOAT and DOUBLE in terms of storage and accuracy?

7When storing time zone–aware data, what are the differences in behavior and use cases between DATETIME, TIMESTAMP, and CONVERT_TZ() in MySQL?

8If you define a VARCHAR(255) column with utf8mb4 encoding, how does MySQL calculate the maximum possible storage size for that column, and how does it differ from CHAR(255)?

9What are the advantages and limitations of using ENUM and SET data types in terms of performance, flexibility, and schema evolution?

10Explain how MySQL internally stores and sorts values of type BLOB and TEXT. What happens when you try to index a TEXT column?

11How do signed and unsigned integer types affect query results, index usage, and storage size? Can you demonstrate an example where overflow behavior differs?

12In what scenarios would using a JSON column be preferable to a normalized table structure, and what are the internal storage and indexing implications of JSON in MySQL 8.0?

13How does MySQL’s BIT(M) type differ from BOOLEAN, TINYINT(1), and binary string types (BINARY, VARBINARY) in terms of storage, representation, and retrieval?

14If you define a composite index on multiple columns of different data types (e.g., INT, VARCHAR, and DATE), how do the internal data type differences influence sorting, comparisons, and index efficiency?

15What are the practical implications of using CHAR vs VARCHAR for columns in InnoDB tables with varying row lengths and frequent updates? How does this choice affect row fragmentation and performance?

mysql

Functions and Operators

07 / 15

When storing time zone–aware data, what are the differences in behavior and use cases between DATETIME, TIMESTAMP, and CONVERT_TZ() in MySQL?

Difference Between DATETIME, TIMESTAMP, and CONVERT_TZ()

MySQL stores time zone–aware data differently depending on whether you use DATETIME, TIMESTAMP, or CONVERT_TZ(). Each serves specific use cases based on time zone handling and storage behavior.

DATETIME

1
Stores a date and time exactly as entered, without any time zone conversion.
2
Does not track or adjust time zones internally.
3
Suitable when you want to store local time values exactly as they occur.
4
Common for scheduling events, logs, or timestamps where local meaning is fixed.

TIMESTAMP

1
Stored internally in UTC, but automatically converted to the session's time zone for display.
2
Converts from session time zone → UTC on insert, and UTC → session time zone on select.
3
Automatically affected by daylight savings and time zone changes.
4
Ideal for global applications requiring consistent and comparable time values.

CONVERT_TZ() Function

1
Used to manually convert a DATETIME or TIMESTAMP from one time zone to another.
2
Does not change the stored value; only transforms it in the query result.
3
Depends on MySQL time zone tables being loaded.
4
Useful when you need explicit control over source and target time zones.

Key Differences and Use Cases

1
DATETIME stores values as-is with no automatic time zone handling.
2
TIMESTAMP stores values in UTC and converts automatically for users.
3
CONVERT_TZ() is used for manual time zone adjustments in queries.
4
Use DATETIME for local-event-based data, TIMESTAMP for universal logging, and CONVERT_TZ() for custom conversions.